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TELNET TERMINAL TYPE OPTION 


Status of This Memo 
This RFC specifies a standard for the ARPA Internet community. Hosts 
on the ARPA Internet that exchange terminal type information within 
the Telnet protocol are expected to adopt and implement this 
standard. Distribution of this memo is unlimited. 
This standard supersedes RFC 884. The only change is to specify that 
the TERMINAL-TYPE IS sub-negotiation should be sent only in response 
to the TERMINAL-TYPE SEND sub-negotiation. See below for further 
explanation. 

1. Command Name and Code 
TERMINAL-TYPE 24 

2. Command Meanings 


IAC WILL TERMINAL-TYPE 


Sender is willing to send terminal type information ina 
subsequent sub-negotiation 


IAC WON’ T TERMINAL-TYPE 
Sender refuses to send terminal type information 
IAC DO TERMINAL-TYPE 


Sender is willing to receive terminal type information ina 
subsequent sub-negotiation 


IAC DON’T TERMINAL-TYPE 
Sender refuses to accept terminal type information 
IAC SB TERMINAL-TYPE SEND IAC SE 


Sender requests receiver to transmit his (the receiver’s) terminal 
type. The code for SEND is 1. (See below.) 
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IAC SB TERMINAL-TYPE IS ... IAC SE 


Sender is stating the name of his terminal type. The code for IS 
is 0. (See below.) 


3. Default 
WON’ T TERMINAL-TYPE 
Terminal type information will not be exchanged. 
DON’ T TERMINAL-TYPE 
Terminal type information will not be exchanged. 
4. Motivation for the Option 


This option allows a telnet server to determine the type of terminal 
connected to a user telnet program. The transmission of such 
information does not immediately imply any change of processing. 
However, the information may be passed to a process, which may alter 
the data it sends to suit the particular characteristics of the 
terminal. For example, some operating systems have a terminal driver 
that accepts a code indicating the type of terminal being driven. 
Using the TERMINAL TYPE and BINARY options, a telnet server program 
on such a system could arrange to have terminals driven as if they 
were directly connected, including such special functions as cursor 
addressing, multiple colors, etc., not included in the Network 
Virtual Terminal specification. This option fits into the normal 
structure of TELNET options by deferring the actual transfer of 
status information to the SB command. 


5. Description of the Option 


WILL and DO are used only to obtain and grant permission for future 
discussion. The actual exchange of status information occurs within 
option subcommands (IAC SB TERMINAL-TYPE...). 


Once the two hosts have exchanged a WILL and a DO, the sender of the 
DO TERMINAL-TYPE is free to request type information. Only the 
sender of the DO may send requests (IAC SB TERMINAL-TYPE SEND IAC SE) 
and only the sender of the WILL may transmit actual type information 
(within an IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal 
type information may not be sent spontaneously, but only in response 
to a request. 


The terminal type information is an NVT ASCII string. Within this 
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string, upper and lower case are considered equivalent. The complete 
list of valid terminal type names can be found in the latest 
"Assigned Numbers" RFC. 


The following is an example of use of the option: 
Host1l: IAC DO TERMINAL-TYPE 
Host2: IAC WILL TERMINAL-TYPE 
(Hostl is now free to request status information at any time.) 
Host1l: IAC SB TERMINAL-TYPE SEND IAC SE 
Host2: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE 
6. Implementation Suggestions 


The "terminal type" information may be any NVT ASCII string 
meaningful to both ends of the negotiation. The list of terminal 
type names in "Assigned Numbers" is intended to minimize confusion 
caused by alternative "spellings" of the terminal type. For example, 
confusion would arise if one party were to call a terminal 
"IBM3278-2" while the other called it "IBM-3278/2". There is no 
negative acknowledgement for a terminal type that is not understood, 
but certain other options (such as switching to BINARY mode) may be 
refused if a valid terminal type name has not been specified. In 
some cases, a particular terminal may be known by more than one name, 
for example a specific type and a more generic type. In such cases, 
the sender of the TERMINAL-TYPE IS command should reply to successive 
TERMINAL-TYPE SEND commands with the various names, from most to 
least specific. In this way, a telnet server that does not 
understand the first response can prompt for alternatives. However, 
it should cease sending TERMINAL-TYPE SEND commands after receiving 
the same response two consecutive times. Similarly, a sender should 
indicate it has sent all available names by repeating the last one 
sent. Note that TERMINAL-TYPE IS must only be sent in response to a 
request (TERMINAL-TYPE SEND), because a host that sent TERMINAL-TYPE 
IS and then received TERMINAL-TYPE SEND couldn’t determine whether 
the other host was requesting a second option or the TERMINAL-TYPE 
SEND and the TERMINAL-TYPE IS crossed in midstream. 


The type "UNKNOWN" should be used if the type of the terminal is 
unknown or unlikely to be recognized by the other party. 
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The complete and up-to-date list of terminal type names will be 
maintained in the "Assigned Numbers". The maximum length of a 
terminal type name is 40 characters. 
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